There are many apparatuses which accept a plurality of setup values input from the user via a user interface (to be also referred to as a “UI” hereinafter) and are controlled based on these setup values. An example of such apparatus is an image forming system (printer system) which is connected to a host computer, and executes an image forming process based on information set by the host computer. The host computer of the printer system normally has a so-called printer driver for controlling a print process, and a print process related program including a UI that accepts a print setup and the like from the user.
Every time a setup value input from the user is accepted via the UI, the print process related program evaluates the relationship between the input setup value and an associated one of a plurality of setup values set so far, and checks if conflicts occur between the setup values. Examples of conflicts include a setup disadvantageous for the user (e.g., a setup of a two-sided print process for an OHP sheet set as a print medium), a setup that tries to make a printer execute impossible operations, and the like.
If any conflicts are found, conflict resolution for resolving such conflicts must be executed.
In a conventional method, a plurality of setup value conditions (conflict resolution rules) that require conflict resolution are saved as a list in, e.g., a file, and conflict resolution is executed by loading that file by a conflict resolution program. Such method is better since the conflict resolution program can be versatilely used independently of a specific setup value.
Some conflict resolution executes a process for informing the user of not only a change in setup value in a data structure but also a change in setup value on the control of the UI (to be also simply referred to as “control” hereinafter), and a process for informing the user that a given setup item cannot be directly changed (by, e.g., a mouse) by graying out a control (displaying the setup item in light gray).
As a result of the conflict resolution including such process, the user can recognize that a control which is inhibited from being used depending on another item cannot be directly changed, since that control is grayed out, but he or she cannot easily understand a cause of denial of the direct change (e.g., the other item with dependency) if such cause is present on another one of a plurality of sheets and dialog boxes. To solve this problem, some program displays a message that contains a reason why the direct change of the control is denied near the grayed-out control.
Conventionally, in order to display the reason why a direct change of a grayed-out control is denied, a dedicated reason detect program must be prepared in addition to a description of the conflict resolution. In order to accurately detect a reason, program codes of reason detect processes corresponding to processes for graying out a control are required. Preparation of such program codes requires much labor, and upon adding/changing grayout processes, reason detect processes readily encounter errors or inconsistency.
Also, a plurality of reasons for graying out a given control are often present (for example, that control cannot be used unless a specific device option (e.g., a staple finisher) is attached, and the control has an exclusive relationship with another item). In such case, the reason detect processes become more complicated, and the aforementioned problem upon preparing for the program becomes more conspicuous.
In some cases, setup values of an internal structure which saves setups on the user interface may be directly changed by another program without the intervention of the user interface (i.e., without displaying the user interface). In such case, conflicts with items associated with the changed setup values must be evaluated, and the same conflict resolution as that executed when the user changes them via the user interface must be executed.
Upon changing the setups of a device or during link processes to an application, the consistency of setups in the internal structure may be lost. Upon opening the user interface or before a print process is executed, a matching process for overall data is required. In such case, the same matching process results as those obtained when the user makes operation by opening the user interface must be obtained.
Both the conflict resolution and the matching process for overall data executed when the user interface is not displayed use the same conflict resolution rules. Hence, a conflict resolution module may be divided into a data processing module and user interface processing module, and only the data processing module may be used when the user interface is not displayed.
However, in a process executed when the user interface is not displayed, even an item, which cannot be directly changed since it is grayed out (a setup item is displayed in light gray) while the user interface is displayed, may undergo an inadvertent change process upon generation of a change request event. For this reason, it is difficult to use a common processing module.
The matching process for overall data must be done under a different precondition. That is, when the user interface is displayed, matching with an associated item is evaluated to have as a start point an item whose setup has been changed, and if an update process is required, matching with the next associated item is evaluated. However, in case of the process for entire data, there is no start point upon changing the setup, and overall check is required. Hence, it is difficult to use a common processing module.
However, if these processes are implemented as independent modules, independent processing codes must be created although they have nearly the same algorithms. In addition, upon adding or changing the conflict detect processes, respective processes may readily encounter errors or inconsistency.